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In the Competitive Analysis phase you will be focusing on the competition that is 
currently present and the potential competition that could arise in your targeted 
market Below is a list of where you should start your research. 



□ Primary Research 

• Outside Consultants 

• Search Engine Query 

□ Secondary Research 

• Business Unit competitive profile 

• Assess existing web sites 

• Competitor's annual reports 

• Trade publications 

• Analysts reports 
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2.05-Select Creative Option 



Overview 

Selecting the creative option will serve as the foundation of your 
site image from here on forward. 

□ When selecting the creative option, keep these elements in mind: 

• Does the design meet key criteria? 

s Will it cost significantly more (time/money) than other options? 
s Include the developer at this stage to be certain that what creative is 
suggesting is feasible and time/cost effective. 

• Does the design conflict with any team Standards? 

• Is the design par for what is currently on the web or better? 

• Is the option consistent in design? 

□ Usually the creative resource will present a few different creative comps for 
evaluation. Although the goal is to choose one, a hybrid of the proposed 
comps is usually constructed. As you select the creative option, you should 
note any modifications or changes that you would like to see in the final 
product. You should expect some of the suggested changes to be reflected 
in the snapshot designed in step 2.09 and the final changes to occur in step 
3.09 during the refinement process. 
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L 01 ^Approved Portal 



Once management has approved the portal or web site, the next action that needs to 
be taken is Domain Name Registration. What you need to do: 



□ Brainstorm a list of possible URLs for your site. 

• One of these URLs will act as your primary address and the others will 
serve as aliases for redirects (if you choose to register them). 

• You may want to use this list of URLs during the customer research 
phase to find which are more/less desired from a marketing standpoint. 
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7. 02-Customer Research 




In the Customer Research phase you will be focusing on the various marketing 
aspects of your proposed web site and target audience. Below is a list of where you 
should start your research. *The VOC collected here will drive site functionality and 
content Remember, it is crucial to collect true VOC. (see step 1.05) 



i u 



□ Primary Research 

• Focus Group -> VOC 

• Surveys -> VOC 

• Outside Consultant Research 



□ Secondary Research 

• Internal Research (BU's) 

• Industry Reports 

• GEC Intranet Links 
s S&P Reports 

✓ Stats USA 

S Forrester Reports 
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1 ,04-Business Unit Interviews 




Overview 

Whether you are creating a cross-business portal or a web site for your business 
unit, initial management buy-in is crucial to the success of your site. 

□ Try to get the highest level of management involved 

• You want to keep the discussion at the highest possible level to obtain buy 
in and commitment from the business unit. 

□ Identify the dedicated Business Unit team (E-business, Marketing, Sales, and 
Underwriting). 

• Schedule meetings with this group and the management that elected them 

□ Be sure to completely understand what the Business Unit does. 

• Start with a play back of your understanding of the Business Unit instead 
of having them explain it to you from ground zero. 

• Understand Business Unit sales 

• Understand Business Unit Underwriting 

• Understand promotional schedules (for possible leveraging) 

• E-business initiatives (what online tools do they have, calculators, wizards, 
etc) 

• Where and how they play in their market segments and where they do not 
play. 

• Business Unit S2 and Operations plans 

• Business Unit Core Competencies 
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Define Business Unit involvement and gain commitment 

• Budget contributions 

• Time 

• Resource allocation 

• Copy contributions and who will provide it 

• Technology 

• Prompt future lead-tracking need 

Get Business Unit expectations of the proposed web site 
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Requirements 

1. OS-Functional Specifications Document 



Overview 

The Functional Specifications Document will provide the framework for what 
needs to go into the production of the site. It is extremely important to detail 
your functional specifications so that when it is time to select your vendors, 
you select vendors with core competencies that match your requirements. 

□ You need to specify: 

• Functional Requirements - Major site functionality (e.g. wizards, video, 

animations, etc) 

• Data Requirements - Required data to be collected, processed, and/or 

stored. 

• Look and Feel Requirements - Specific design requirements (e.g. site 

must have consistent look and feel as an 
existing site) and navigation elements. 

• User Requirements - Groups of targeted users and utility of site for each. 

• Architecture Requirements - Any constraints that the developer must work 

with (e.g. must run on an existing architecture). 

• Operational Requirements - (e.g. operating systems, browsers, etc) 

• Content Requirements - Content to be provided by internal and third 

party resources. 
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*Specific to your Content Requirements, deciding what and how you are going to 
present your content is one of the single most important tasks in the Web 
Development Process. From a Six Sigma perspective, you want your VOC to 
drive what you are going to present on your web site, which will in turn dictate the 
kind of content that needs to be collected. 

• At this point you need to make a strategic decision about how you are 

going to move forward. You need to determine your success factors and 

rate them against: 

V Using existing content and copy to drive the design and what you are 

going to offer on your web site, vs. 
s Using VOC to drive the CTQs to design what your customers want 

offered on the web site; then collect and/or create the content and copy 

to support the design. 
s Sometimes VOC will indicate a need that is not justifiable in the context 

of the scope of the web initiative. Be sure to use prudent business 

judgement to determine the customer needs that you will address. 

Remember to focus on the critical few; use the 80/20 rule when 

determining how to prioritize CTQs. 
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Vendor Selection Criteria 



Overview 



As mentioned before, it is strongly advised that you spend ample 
time on due diligence with respect to vendor selection. It is crucial 
that you let your requirements drive vendor selection. Experience 
has shown that selecting a technology vendor before knowing your 
requirements may lead to proprietary solutions that may not be in the 
best interests of GE. 

As you begin vendor selection you need to keep the following in mind: 

• Approved vendors. 

• References 

S From various Business Units 
S From other internal resources 

The site's functional requirements will drive the decision for what types of 
vendors you will need (creative, development, special web tools, etc). In 
addition, you should come up with a ranking system of requirements needed 
versus vendor capability. 

1 . Determine the types and number of vendors you think you will need to 
build your site. 

S Bucket the types of functional areas and/or technologies needed. 

V Which vendor will be playing the "lead" role for the other vendors to 
follow? One suggestion is for the development vendor to hold the 
"lead" role since all of the components will eventual be rolled into 
development for production. 

2. Use QFD or The House of Quality (Pugh Matrix) 

S Give weights to requirements; score each vendor on the requirements 
to see which one has the core competencies to meet your need. 
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When choosing a vendor it is strongly recommended that you look into the 
vendor's methodology for project management, quality assurance, and 
production. We have found that a solid methodology creates the least 
amount of confusion, resulting in a better product on schedule.. 
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1.07-Select Vendor (Copy Resource) 

Overview 

A key take away in selecting your vendors is sufficient due diligence. Take the 
time up front to clearly establish your needs and rank the various vendors 
accordingly. Depending on your site, there are three main functional areas 
that need to be covered: creative, copy, and coding. This step is dealing with 
the selection of vour coov resource. 

□ Make the decision whether to Make of Buy 
• Select Copy Resource 

□ Interview or meet specific head(s) of the copy team 

□ Get commitment of team member(s) for duration of assignment 

□ Priority of characteristics for your copy resource: 

1 . Internal, web experienced writer 

2. Internal Resource 

3. Outside vendor with client-specific and industry knowledge 

4. Outside vendor with little or no client-specific experience, but has industry 
knowledge 

□ If you do decide to outsource copy development, you will still need to have 
internal resources available for input, questions, materials etc. 
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1 .08-Finalize Routing Rules 



Overview 

Finalizing the routing rules will be most pertinent if you plan on having a wizard on 
your site that uses logic to drive a user to a specified answer, location, etc. It is 
crucial to obtain complete information and consensus on the logic being used. Once 
this logic is coded into the wizard it becomes much more challenging and expensive 
to make changes to it 



□ There are many ways to go about gathering routing rules; below are some 
possible approaches. These approaches are based on finalizing routing rules 
with multiple Business Units, but they can be used in any situation where 
consensus is needed. 

1 . Have all of the Business Units or parties involved participate in a workout 

2. Have Business Unit vs. Business Unit come to agreement on their own 

S Lay the ground rules down and let them figure out what belongs where. 

3. Meet with each Business Unit individually 

s This will only be possible in situations where the routing rules are "cut 
and dry" 

□ One suggestion is to have copy resource attend these meetings. 

• This will help the copy resource better understand the type of information 
and context in which it needs to be presented on the site. 
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1.09-Select Vendors (Creative & Development) 

Overview 

Again, the key take away in selecting your vendors is sufficient due 
diligence. Take the time up front to clearly establish your needs and rank 
the various vendors accordingly. One suggestion is to take a Check and 
Balances approach. Having more than one vendor will help avoid 
proprietary solutions which may be best for the vendor but not for GE. 
Depending on your site there are three main functional areas that need to be 
covered: creative design, copy, and coding or production. 

Use Functional specifications to determine the resources needed (let your 
requirements drive the need) 
Make the decision to Make or Buy 
• Select Creative and Development Resources 
Interview or meet specific head(s) of associated team(s) 
Obtain commitment of team member(s) for the duration of the assignment 

*As mentioned in step 1.06 , the use of Global Development Centers is crucial 
to foster lower development costs.). 



□ 
a 



□ Pay special attention to the vendors' development and production 

methodologies when selecting your vendors. Experience has shown that 
choosing a vendor with a strong methodology yields less confusion, 
misdirection, and rework. 
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J . 1 0-Budget Forma tion 

Overview 

At this stage you should be able to derive a firm budget for the creative 
and copy resources, and a Rough Order of Magnitude budget for the 
development resource. The functional specifications should drive the 
creative and copy resource budgets. The reasoning behind the ROM 
budget is that the development resource is not going to know exactly 
what they are developing until after the creative and copy resources 
design a snapshot (step 2.09) of the finished product Once the snapshot 
is complete, the development vendor will design the relevant 
technological options, and from this a firm budget will be created 
fstep2.15) . 
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1. 11 -First Pass Individual Project Schedules 



Overview 

At this stage each vendor should create their individual project plan for 
the piece of the process that they are responsible for. The individual 
project plans will then be rolled up into a master project plan in the 
next step. 
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2.03 



Overview 

The first step in the Analyze phase is to merge the independent 
vendor project schedules into one master project plan. The creation 
of the master project plan should be lead by team with assistance 
from the lead vendor. If this path is taken, accountability is reduced 
to one vendor who is in turn responsible for updating and holding to 
the master schedule. When you approach the master project plan 
keep the following points in mind: 

Integrate individual vendor project plans 

Set integrated milestones and tollgates 

Portal leader and lead vendor should review for integrity 

• Are there any tasks missing in the master project plan that were specified 
in the Functional Specifications document 

• Does the project plan take into account the queuing of additional 
resources (i.e. code review) 

Our recommendation is to have one vendor accountable for delivering and 
maintaining the master project plan. 
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2 M2-Kick-Off Meeting with all Vendors 
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Overview 



The kick-off meeting will prove to be a very important step in the 
overall development process; here you will lay down the ground rules 
for moving forward. Below are some points that should be addressed 
at this meeting. 



□ Set ground rules for project 

• Set reporting structure (e.g. all vendors report to lead vendor, lead vendor 
is the single point of contact to team) 

S Determine the Roles and Responsibilities of each vendor's team 
* Set a single point of contact for each vendor. This will reduce 
confusion in future handing of change requests, updates, etc, 

• Set an escalation process for all vendors if issues such as slippage or 
scope creep arise. Set a change order request process 

• Set a notification process if vendor resources are changed 

• *Set Weekly / Semiweekly conference calls and structure (i.e. use the 
master project plan and determined milestones as checklists during these 
calls). This will help identify any problems on a weekly basis as opposed 
to waiting and finding them out downstream. 

S Report % Complete vs. Schedule 
s Report Dollars Spent vs. Budget 
a All vendors to exchange contact information 

□ Team and all vendors to sign-off on master project plan 
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2.03-Design Wireframe 




Designing the wireframe is a crucial step in designing your site. 
The wireframe is basically a skeleton or framework of how you want 
your homepage and lower level pages presented. 



□ The wireframe will address: 

• Layout of the page elements 

<s Header and footer placement 

V Logos or branding 

s Where copy will be placed 

s Placement of synchronized content 

s Where any online tools (wizards, calculators, etc.) will be placed 

• The navigational schema 

S Where the main navigation will be situated on all pages 
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2.04-Develop Creative Options 




Developing the creative options is basically a function of wrapping 
various creative templates around the wireframe that has previously been 
created. Hence, the creative resource will need the wireframe to design 
the various options. The creative resource should design various creative 
site templates as per your direction. 



□ The creative options will most likely be presented as static GIF or JPEG 
images, which will then be used by the production resource when building the 
site. 



□ The creative resource will develop X number of creative options addressing: 

• Overall look and feel of the homepage and lower level pages 

• Applicable functional requirements previously specified (stepi.07) 

• Online tools (wizards, calculators, etc.) 

• Navigation, Pop up windows, rollovers, etc. 

• Creative ideas on the presentation of any online tools (wizards, 
calculators, etc.) to be used 

FIG. 27a 



You should analyze existing team web sites for ideas and best practices 
when brainstorming the possible creative options. In some cases there may 
be little if any effort spent here if you can find usable existing templates. 

It is recommended to have the creative resource first create the options for 
the homepage; then move to the lower level pages after approval. 
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2. 06-Begin Content A udit 




Overview 

The purpose of this step is to take a first pass at gathering the 
content which will be used to develop a representative "snapshot" 
(see step 2.09) of the final copy deck and creative design. 
Gathering content is one of the single most time consuming tasks. 
It is our recommendation that agreement on the type and depth of 
content being collected is made before a complete audit is 
conducted. This will allow you to attack issues up front to avoid 
plan slippage due to miscommunication of requirements. 

Some suggestions where to start the content audit are: 

• Design a framework of how and what you are going to collect 

• Business Unit web site print-outs 

• In-process Business Unit offerings (i.e. new products or proposed web 
solutions, etc.) 

• Existing BU tools/wizards, calculators, etc. 

• Have Business Units bring print materials, marketing materials, etc. to the 
content workout. 

• Benchmark ideas from Competitive Analysis 



□ Be sure to clearly define who has the responsibility of the content audit. 
• One suggestion is that the web site leader or an internal company 

FIG. 28a 



resource takes the lead for the content audit. Here you can leverage 
company knowledge, networking, and a better understanding of the business. 
Experience has shown that having a third party lead the content audit may 
slow the process since they do not have the same internal resources that 
your team has. 
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Overview 



Now that a first pass of content has been collected, it is time to start 
thinking about how the content will take shape in the web site. Since you 
will only have a small amount of content collected at this point, you will not 
be able to complete the content hierarchy. However, this will give you a 
head start when you complete the content hierarchy in step 3.04 , Again, the 
main purpose of this step is to prepare for the snapshot to be created in 

□ Web leader, copy resource and creative resource to give input about where 
the copy will be presented in the wireframe design. 

• Determine where the copy is going to be placed on the home and lower 
level pages, (what buckets of copy do you have to present?) 

• Look for existing templates for content layout structures 

• Determine a click strategy (see corporate guidelines for any requirements) 



□ Refer to step 3.04 for more information about the content hierarchy. 
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2.08-Create First Pass of Copy 



Overview 

This step is intended to produce enough copy for the snapshot that 
will be created in the next step. The team needs to decide what type of 
copy should be created here (e.g. copy for the Homepage andX 
number of lower level pages). The copy resource should not attempt 
to create the entire copy deck at this point; the copy deck will be 
created once all of the content has been collected and the content 
hierarchy is complete. 
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2. 09-Create Snapshot 



Overview 

This step will allow the copy and creative resources to put actual content into 
the framework developed, so that a "snapshot" of the pages can be viewed 
before it is driven to production. Past experience has shown that this may be 
a good idea, attacking these components up front as opposed to dealing with 
unacceotable coov and desian issues later in the eta me. 

□ In order to create the snapshot you must first have the initial content audit and 
wireframe complete, the agreed copy created, and have selected a creative 
option. 



□ The snapshot will basically be a static image combining content and copy with 
the creative option chosen so that you can get an idea of what the final 
product will look like. Having the creative and copy resources develop this 
snapshot early in the process will allow you circumvent false expectations in 
the future. 

• You should request a snapshot of both the home page and one lower level 
page. 



□ This step may be an iterative step if the web team is not satisfied with the 
snapshot created. If this is the case, you should return to step 2.03 and work 
forward to iron out the discrepancies. 
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2. 10- All Vendor Meeting 



Overview 

The purpose of the all vendor meeting is to get everyone on the same 
page as you begin to define your technological options for development 
and move into production. The goal is to have all parties leave the 
meeting with a full understanding of what they are responsible for and 
the attainability. The site owner should lead this meeting; the lead 
contractor should have major input 

□ There are several points that should be covered during this meeting: 

• Ensure that everyone is at the same point of understanding with respect to 
each vendor's responsibility and how their work ties into the whole picture. 

• Present the snapshot images of the homepage and lower level page(s) 
that have been created. 

s You will want to ask for constructive criticism at this point since the 
next step is for the development vendor to take this snapshot and 
design the relevant technological options for it. Note that when the 
creative and copy resources move to production they will 
refine/complete the selected creative option and framework. 

s Are there any issues with respect to the reality of the snapshot? (i.e. 
are there enormous costs or limiting technologies involved) 

• This meeting should also serve as a place to flag any major problems or 
issues dealing with vendor to vendor relationships and/or vendor to 
company relationships. 
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2.11 -Development Vendor to Propose Relevant Technological Options 
Overview 

At this stage in the game you know what you are going to offer on the site 
and the online tools that you want to use, now it is a question of what 
technology is going to make it happen. It is very important that the 
developer details the various technological solutions that will suit your 
need. For example, you could code your entire site in HTML or XML. What 
are the pros/cons of each option? Which serves your need best? 

□ Not only should the developer offer various technological solutions, they 

should compare and contrast the various offerings. 

• Pros and cons for each option presented with respect to: 
s Platform options and their scalability - ability to interface 
s How they stack up to today's technology standards 

> How soon will they be outdated 

v Do they support company's lowest common denominator standard 

> (e.g. what browser version do you have to cater to) 

<s What are the business justifications to use one technology over 
another. 

V How flexible are they to maintain 

* Does the developer have the skill set, or are they going to subcontract 
it out. 

> How do GDCs fit into the picture? And do they have the necessary 
skill sets? 

FIG. 33a 



s Compatibility with your current components 

> Does company already have licenses with the proposed 
technologies? 

> Internet metrics tracking software 

> Hardware structure 

What are the short and long term implications? 

What is the timeline and costs associated with each option presented? 
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2. 12- Analyze Options 

Overview 

The next logical step is to analyze the technology options that the 
production vendor has presented to you so that you can make an 
informed decision as to which the optimal choice is. 

□ Similar to the QFD or House of Quality suggested in the Vendor Selection 
Criteria in step 1,06 , you should rate the relative options against your needs 
and the site requirements. 

• Give weights to your requirements and score each option to find which 
one satisfies your needs profitably . 

s Let the main drivers be the decision of Cost vs. Time vs. Functionality 
s Refer to step 2.11 for ideas of what you should be scoring 
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2.13 - Recommendation by Web Team 



Overview 

Now that you have analyzed the options you need to package 
your recommendation to "sell" it to management 

□ When presenting your recommendation to management you need to bring the 
details up a level and focus on: 



• The creative options presented 

• Overall site requirements versus what the option offers 

• One time sunk costs 

• Will current hardware systems/structure support the option? 

• Leveragability of the option in the future (i.e. other sites to be launched) 

• Scalability 

• Confidence in the vendors chosen 
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2.14-Decision by Management 



Overview 

This step is relatively self-explanatory. After your recommendation 
to management, a decision on how to move forward will be made. 
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2.1 5 -Firm Development Vendor Budget 



As you may recall, in step 1.10 the development vendor derived a 
Rough Order of Magnitude (ROM) budget for the development costs. 
At this stage, you now know what the inputs are from the creative and 
copy resources, and the technological option that the development 
vendor will be using. You should now be able to firm up the ROM 
budget previously created to reflect your costs moving forward. 



The first step in firming the development cost is to revisit the Master Project 
Plan (2.01) . Since cost is a function of time, unless a fixed price contract is 
used, you may need to refine the project plan to reflect any changes that 
need to be made. 

• Has there been any significant development changes since the master 
project plan was created? 



□ You also need to take into consideration the use of GDCs in the development 
environment. Will any major changes to the project plan effect queuing of 
GDCs or their involvement? 



FIG. 37 




Analyze 

2.16 Design Acceptance 



Overview 

^ Now that the snapshot has been created and the technological 

ll t option has been chosen, the company web team should give their 

acceptance to move forward, always keeping in mind Cost vs. 
!J- Time vs. Functionality. 

■ hs. 

, q □ By the end of this meeting, company and all vendors should sign off on all of 

1 W the requirements up through the Analyze phase and go over what is expected 

;i from each vendor during the Development, Testing, and Implementation 

phases. 

I. JL , 

^y 
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3. 01 - Complete Content A udit 

Overview 

Now that everyone is in agreement of the type of content to be 
collected you can drive the content audit to completion. Be 
proactive during this phase; Experience has shown that the 
content audit, if done inefficiently can become the single largest 
bottleneck in the process. It is advised that the site leader drives 
this step due to the advantages of having an internal resource 
collecting business material. Keep in mind that that the content 
audit should be directed by the VOC collected. 

Depending on the type of site you are developing, the level of effort needed to 
find the necessary content will vary 



Some suggestions for collecting content are: 

• Continue using the framework for collecting the content designed in step 
2.06 . 

• Business Unit web site print-outs 

• In-process Business Unit offerings (i.e. new products or proposed web 
solutions, etc.) 

• Existing BU tools/wizards, calculators, etc. 

• Have Business Units bring print materials, marketing materials, etc. to the 
content workout. 

• Benchmark ideas from Competitive Analysis 
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3.02-Gap Analysis 



Overview 

The gap analysis is basically a function of analyzing the content 
framework that you have designed to find what you have collected and 
what you are missing. 

□ With respect to your framework what else do you need to collect? 

• Are there any CTQs that have not yet been covered? 

• Is the content you have collected detailed enough? 

• Have you satisfied any alliance possibilities / Content partners 
s News feeds 

s Articles 

S Interactive tools 
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3. 03-Collect / Create Missing Content 

Overview 

Now that you know what content you are missing, you need to collect it 
andlor create it depending on what you are missing. 



□ Refer to steps 2.06, 3,01. and 3.02 
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3.04-Content Hierarchy 




Now that you have collected all of the content you need to put some 
structure around it The Content Hierarchy will provide the logical 
positioning of the content throughout the site. 



□ This step will basically define what content goes where (i.e. homepage, lower 
level pages, pop-up windows, etc) 
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3. 05- Write Initial Copy Deck 



Overview 

Developing the Content Hierarchy and site framework before writing 
the initial copy deck will increase the focus of converting content to 
copy, thus limiting time spent on layout and positioning. 

As your copy resource begins writing the initial copy deck, the team needs to 
further clarify the story (or flow) for the site. Starting with the Homepage, 
each lower level page should support or give a more in-depth look of the 
previous page or overall mission of the site. Each page should have a 
specific purpose or intent for the user. 

• At this point you should start to think about Search Engine Optimization 
(steo3.12) . SEO deals with optimizing each page of your site so that 
users can find it when searching online. Since SEO consists of 
formulating titles, keywords and descriptions of each page, it would be 
best to start this task during the creation of the copy deck. 



FIG. 43a 



Here are some things that the copy resource will need to write the initial copy 
deck: 

• All of the content previously collected 

• The Content Hierarchy (3.04) 

• The wireframe (2,03) built for the Homepage and lower lever pages, (the 
snapshot created in step 2.08) 

S Since the copy resource won't be building the copy deck in HTML, one 
suggestion is to recreate the template designed in 2.08 into a word 
processor format. Writing the copy deck in this type of template will 
allow both the copy and the look and feel to be evaluated in an easily 
edited format. Putting the copy in this type of design will further reduce 
false expectation issues in the future. 
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3.06-Content Reviews 




Overview 

Now that the initial copy deck has been written, there are a series of 
reviews that must take place to ensure completeness and integrity 

nftht> nnnu. 

The following parties have a vested interest in reviewing the copy deck: 

• Portal leaders to review for content satisfaction and integrity 

• Legal to review for integrity. This is a great time to get legal input instead 
of waiting until site launch. This will potentially divert any bottlenecks due 
to a review waiting period. 

• Business Unit to review content 

s Send the copy deck to the vested BU parties for review. Set a 
deadline for when you are willing to take changes. 

s The goal of the Business Unit approval is to make sure that everyone 
is satisfied with the content that is being presented. It is recommended 
that all suggestions/changes be made to the copy deck at this stage; it 
will cost the team much more time and money to make content 
changes in the future compared to making them now. 

v This will be the last major Business Unit review of the content. Be sure 
to approach this step with the end goal of content completeness and 
integrity in mind. 
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Overview 

This step is fairly self-explanatory. After the content review you need 
to decide which requests should be focused on, what to ignore, and 
what to act on; make the changes accordingly. 
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3.08-Final Copy Milestone 





Developme 






nt 






Vendor's 






Process / 






Methodolo 






gy 






3.12 





Overview 

With the incorporated copy feedback is in place, the last step for the 
copy resource is to get approval and pass the copy deck to the 
production resource. 

This milestone should address: 

• Company Legal Sign-off 

• Portal Leader Sign-off 

• Development resource to sign off that the copy deck covers what they 
need to push forward. 

• Handoff to production to integrate copy and creative 

Go to the Caution step before moving forward. 
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Overview 

Previously, the creative vendor created a snapshot of what the 
creative option would look like for the home page and lower levels 
pages. Now that Creative is in production they need to continue 
working on the creative option design to drive it to completion. Once 
complete, the creative comp will be passed to the production 
resource for development of the actual web site. 
"Refining the Creative Option is an iterative process step. Creative 
design is a very detail orientated and subjective process that gives 
way to multiple refinements. To limit the number of iterations there 
are some proactive steps that can be taken (see step 3.10) . 

In addition, the feedback, ideas, and changes made in steps 2.05 (Selecting 
the Creative Option) and 2.10 (the All Vendor Meeting) need to be 
incorporated as the creative option is refined. 
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Overview 

As previously mentioned, the process of reviewing and updating the 
creative option is an iterative step due to the very detailed and 
subjective nature of creative design. However, below are some ideas 
on how to proactively limit the number of iterations you face. During 
this step the site leader should be reviewing the creative option for 
integrity, satisfaction, and completeness. 

Comprise a list of specifications that you want met in the creative design 

• Start by referring back to your Functional Specifications Document (1.05) . 
Work from here to specify exactly what your requirements and "wants" are 
with respect to the creative design. 

s Is the creative design fulfilling your initial requirements? 

• Be sure that your specifications comply with any company web standards 

• Detail the types of fonts, text sizes, and colors to be used; and those not 
to be used 

• Specify where you want objects and text placed 

• Specify look and feel for any online tools (wizards, calculators, etc) 

• Include the production resource to ensure practicality 



Set an absolute date to lock the requirements 
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3.11 -Final Creative Design Milestone 
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Overview 

With the creative option finalized, the last step for the creative 
resource is to get approval and pass the creative composition 
to the production resource. 



This milestone should address: 

• Portal Leader approval 

• Development resource to sign off that the creative option is plausible and 
covers what they need to push forward. 

Handoff to production to integrate copy and creative 

Go to the Caution step before moving forward. 
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Overview 

At this point your copy, creative option, and development needs should 
be finalized, and all specifications should be frozen. Any significant 
modifications will prove to be very costly if done after this point. 
Remember that the goal of the web development process is to reduce 
time and cost variation to zero! Beware of scope creep. 
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3J2-Development Vendor's Process / Methodology 

Overview 

The Production Resource's Development Process is one of the major steps 
in the building of your site. At this stage the content has been collected, the 
copy deck written and approved, the creative template has been finalized, 
and the technological option has been chosen. 

During the vendor selection process it was emphasized to spend extra time 
analyzing the vendors 9 development methodologies. This is important 
because at this point all of the vendors will be submitting their units to the 
production vendor to integrate them into the web site. 

□ As you move into production, refer to the guidelines set in step 2.02 

• Set an escalation process for all vendors if issues such as slippage or 
scope creep arise. Encased 

• Set a change order request process 

• Set a notification process if vendor resources are changed 

• Set Weekly / Semiweekly conference calls and structure (i.e. use the 
master project plan and determined milestones as checklists during these 
calls) 

s Report % Complete vs. Schedule 
V Report Dollars Spent vs. Budget 

FIG. 51a 



As mentioned in step 3.05 , writing the copy deck, Search Engine Optimization 
is crucial for the success of your site. If you haven't attacked this issue yet, 
now is the time to do so. 

• If you did create your Meta Keywords, Meta Descriptions, and Titles 
before, you should review them to see if any of them need be changed or 
added to with the updates and additions to the copy that have occurred 
since then. 

• In addition, you need to submit your keywords to company search engine. 
This engine is what drives internal searches on your site.. 
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3. 13- Initial Site Review 



Now that the site has been built, the web leader or team can review 
the beta version. Note that at this stage the site and its 
components have not gone through testing. 

The basic purpose of this step is to click through the beta site to check it for 
functionality and completeness. More specifically you should be analyzing: 

• Look and Feel (creative, user experience, flow, etc) 

• Content 

• Navigation 

• Links 

• Online tools (wizards, calculators, etc.) 



□ Note any improvements and the next steps to refine them. 
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4.01-Unit Testing 

Overview 

Now that all of the pieces (units) of the site are complete, it is time to 
test each unit individually. You want to test each unit individually 
before you test the integrated product to find the bugs that are specific 
to a unit *The lead contractor should be accountable for unit testing 
since they have the responsibility of delivering the final site to 
company. 



?U □ Here is an idea of what units the contractor should be focusing on: 

r (see step 4.05 for detailed descriptions) 

! is& • Look and Feel of the site 

!'f • Functionality of the web pages 

l!G • Functionality of any online tools used (wizards, calculators, etc) 

I* • External Functionality Testing 

s Inputs - (i.e. news feed links, etc.) 

S Outputs - (i.e. metrics reporting tags, database feeds, etc.) 
• Customer Contact Vehicle 
V Email 

s Voice over chat 
s Instant Messaging 
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4.02 - System Testing 




Overview 



Once all of the units have been tested in the developer' s 
environment you need to move them to the environment that will 
eventually house your web site. Each unit properly working in one 
environment does not ensure that they will work in another 
environment 



□ This step will involve: 

• Your team's technical leader 

• The developer 

• The company hosting contractor (the contractor who hosts your site) 



a Depending on how your hardware is configured, you will be moving the units 
from the production resource's Development Environment to company's 
Development Environment. Most likely your Development and Production 
Environments are identical, which is why you want to conduct your system 
testing in your Development Environment. 
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4.03-Code Review 

Overview 

The code review is basically a security test to ensure that there are not 
any "holes" or security breeches within the site. This is a mandatory 
step that company standards require before launch. Here are some 
points to keep in mind: 

□ You should queue the resources for the code review well in advance to take 
advantage of cost savings, and to be certain that once the site is ready, the 
code reviewers are too. 

• Your master project plan should give you the necessary information to 
queue these resources early in the process. 

□ What exactly needs to be sent to the code review? 

• Refer to company Code Review standards 

□ There will be multiple code reviews throughout the evolution of your site. 
Each time you fix or add scripts that have a potential security threat, you will 
need to have the code reviewed by a certified vendor. 
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There is also a part of the site code review that should be done by the site 
leader or team, not an external vendor. Review the HTML for: 

• Meta tagging for search engines 

s Are the keywords and descriptions complete and correct? 

• Metrics tagging 

s Check cookies or tags used to track metrics 

• Unnecessary code and/or comments 

Check for unwarranted information or "initials" embedded in your code 
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4.04 - Integration Testing 



Overview 

Now that all of the units have been tested in the Company Environment 
it is time to integrate the units to test if they work properly together . 
Ideally, Integration testing should be conducted in company's 
environment to circumvent similar issues that were found during 
Systems Testing. *The lead contractor should be accountable for 
Integration Testing since they have the responsibility of delivering the 
final site to company. 

□ As the production resource initiates Integration testing, it is advised that the 
site owner and team begin testing the site in parallel. You should start 
testing now so you can get a head start on User Acceptance Testing (step 
4,05) . It is suggested that you simply keep a log of all the errors you find so 
that they can be presented to the production resource during User 
Acceptance Testing. You should not contact your vendor with every issue 
you find since the production resource will find and fix many of these issues 
during their testing; this will only slow the process. 
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4.05 - User Acceptance Testing 



Overview 



At this point in the process, the vendors have completed Unit Testing, System 
Testing, and integration Testing. *As noted during the Vendor Selection 
Criteria step, it is extremely important that you analyze the vendor's Quality 
Assurance processes before choosing the resource. Past experience has 
shown that poor QIA processes lead to rework and missed expectations. 
Now it is time for the site leader and team to continue testing the site for 
integrity and completeness. However, this step should not serve as the first 
complete audit of the site. All major issues should have been dealt with 
throughout the process since you have the weekly calls and milestones in 
place. Here are some key aspects to analyze when testing the site: 



Look and Feel Testing 

• Is the site layout and design reflective of the creative option that was 
chosen and refined? 

S Are all pages consistent? 

• Have all company standards been met? 

• Is the site performing on various platforms? (Apple, IBM, Netscape, 
Internet Explorer, etc.) 

s Does the site cater to the lowest common denominator? Check for 
company standards. 
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• Link Testing 

s Are all links (internal and external) working properly? 

• Mouse-overs and Alt Tags 

S Is the correct and complete information being shown? 

• Flash, Shock Wave 

V Are your interactive tools working properly? On various platforms? 

• Daughter windows and Pop up windows 

S Are such windows being spawned where appropriate? 

• Navigation testing 

V Does the navigation match your content hierarchy and site layout? 
Synchronized Content Testing 

• Is all of the synchronized content matching up in the correct place? 
Online Tool Testing (Wizards, Calculators, etc) 

• Basic functionally 

s Is the unit outcome matching your specifications? 

• Are there any discrepancies with the tool's content, layout or integrity? 
Search Function Testing 

• Is the company search tool working properly for internal searches? 
External Functionality Testing 

• Are all Inputs working properly (i.e. news feed links, alliance links, etc.) 

• Are all outputs working properly (i.e. metrics reporting tags, database 
feeds, cookies, etc.) 

Customer Contact Vehicle 

• Are your email links working? Are the correct email addresses being 
used? 

• Are other means of customer contact working? (i.e. voice over chat, 
instant messaging, etc) 
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• Depending on the time remaining in your project plan, you will be able to 
address some of the minor bugs or fixes before launch. At this stage of 
the process no "major" bugs should appear if all of the milestones to date 
have been satisfied. However, if there are major changes to the site, you 
have two choices: 

1 . Delay the launch and make the necessary changes 

2. Address the major changes post launch 

The goal of this process is to launch the site within the set parameters of your 
budget and project plan. If major issues do arise the decision must be made 
on a case by case basis. * Once User Acceptance Testing is complete, all 
parties should sign off on completeness and integrity of the final product. 
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4.06-Push to Staging 



Overview 



Now that the site has been tested it is time to push the code to your 
Staging environment The Staging environment is a replica of the 
Production (the live) environment You always should push changes to 
Staging first, test it, then push to the Production environment Pushing to 
the Staging environment gives you the ability to test the site as if it were 
in Production, without having it available to the public on the Internet 



To push the code to Staging you need to: 

• Switch the Domain Name System (DNS) to the hosting provider. 

• Developer must have "staging-ready" code prepared and Tared 

• Developer to develop a document for code release. This is basically a list 
of which files go into the various directories. 

• Web master to FTP code to the web server 
s Untar files into the appropriate directory 



FIG. 58 



* 



Code 
Review 

4.03 



Integrati 

on 
Testing 

4.04 



User 
Accepta 

nee 
Testing 

4.05 



Push to 
Staging 




4.06 





Implementation 

4.07 -Testing in Staging 




Overview 

The next step is to test the functionality of the site in Staging. At this 
stage you should not have to retest look and feel, logic, etc; you need 
to verify that the site is working properly in this environment This is 
the same code that was signed off on during the User Acceptance 
phase; hence there should be no differences. 
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5.0 J -Push to Production 




The next step is to push the code to the production server. Once the 
code is in Production, the site will be live for the public to view. 



To push the code to Production you need to: 

• Switch the Domain Name System (DNS) to the hosting 

• Developer must have "staging-ready" code prepared and Tared 

• Developer to develop a document for code release. This is basically a list 
of which files go into the various directories., 

• Web master to FTP code to the web server 
Untar files into the appropriate directory 

Your Site is Live! 
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Overview 

The last step of this process is to test the functionality of the site in 
Production. Again, at this stage you should not have to retest look 
and feel, logic, etc.; you need to verify that the site is working 
properly in this environment. This is the same code that was 
signed off on during the User Acceptance phase; hence there 
should be no differences. 
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